home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 October / EnigmA AMIGA RUN 01 (1995)(G.R. Edizioni)(IT)[!][issue 1995-10][Aminet 7].iso / Aminet / util / arc / PackDev1_3.lha / PackDev.doc < prev   
Text File  |  1995-05-06  |  22KB  |  571 lines
  1. Program(s):         PackDev
  2. Version:            1.3
  3. Author:             Christian Wasner
  4. Date:               06-May-95
  5.  
  6.  
  7. -i) READ THE SECTION ABOUT PARAMETERS !!! THERE ARE MAJOR CHANGES !!!
  8.  
  9. o) Version
  10.  
  11. $VER: PackDev.doc V1.3 (30-Apr-95)
  12.  
  13.  
  14. i) Disclaimer
  15.  
  16. The  author  cannot  be held liable for the suitability or accuracy of this
  17. manual  and/or  the  program(s)  it  describes.   Any  damage  directly  or
  18. indirectly caused by the use or misuse of this manual and/or the program it
  19. describes is the sole responsibility of the user her/him self.
  20.  
  21.  
  22. ii) Copyright/Distribution
  23.  
  24. All  files mentioned in iii) are (C) Copyright 1994, 1995 Christian Wasner.
  25. All rights reserved.
  26.  
  27. These  programs  are  FREEWARE, so no financial donations are required (but
  28. welcome).   They  may  be  freely  distributed  as long as all files remain
  29. unchanged and are included with the distribution.  Distribution on disks or
  30. CDs is permitted only on the disks or CDs from Fred Fish or the Aminet CDs.
  31. Electronical  distibution  (e.g.  by Aminet, mailboxes, modems) is allowed.
  32. Inclusion  into freeware software packages is allowed, inclusion into other
  33. packages must be expressly allowed by me in written form.
  34.  
  35.  
  36. iii) Files
  37.  
  38. The following files should come along:
  39.  
  40. PackDev      (23372 bytes)
  41. PackDev.doc  (21965 bytes)
  42.  
  43.  
  44. iv) Documentation
  45.  
  46. Program:       PackDev
  47.  
  48. Template:      FROM/O,TO/O,P=PACK/K/O,XB=XPKBUFSIZE/K/N/O,M=MEMTYPE/K/O,
  49.                CU=CLRUNUSED/S/O,ETDF=ETDFORMAT/S/O,TDF=TDFORMAT/S/O,
  50.                ALL/S/O,NV=NOVERBOSE/S/O,Q=QUIET/S/O,NC=NOCONFIRM/S/O,
  51.                VIEWFILE/K/O,VIEWFILESYS/K/O,TESTFILE/K/O,BLOCKLIST/K/O,
  52.                PASSWORD/K/O
  53.  
  54. Purpose:       Reading/writing  data  directly from/to filesystems with xpk
  55.                support.
  56.  
  57. Specification:
  58.  
  59. With  this program you can read or write data directly from/to a disk.  The
  60. blocks  of  the  disk are read and stored into a file.  When reading from a
  61. DOS  disk, only the blocks that are used are archived.  When writing a file
  62. from  a  DOS disk to a disk, only the blocks are written that are stored in
  63. the  archive.   Optionally  the data read from a disk can be packed with an
  64. xpk packer.  The program currently only has a shell interface.
  65. All  this  sounds like "Oh no, yet another DMS clone", but this program can
  66. handle  any device with a filesystem (e.g.  DHx:, DFx:, a RAD:  of any size
  67. etc.),  DMS can only handle floppy disks or devices with the size of floppy
  68. disks.   Even  Non-DOS disks can be handled (but then all blocks are read).
  69. Another  advantage  of  PackDev is that is doesn't use stolen code like the
  70. authors of DMS do (see below).  PackDev supports the xpk packer system thus
  71. it's  much  more  flexible  than DMS.  You can use any xpk packer you like,
  72. i.e.   you  can  use a packer suited to the type of data on the disk.  When
  73. comparing  size,  you see that PackDev is only 21 KB long !  If you pack it
  74. with PowerPacker, it would be less than 12 KB !
  75.  
  76. A disk is read as follows:
  77.  
  78.    1. Read device data from DOS
  79.    2. Check  if  the  file  system of the disk is supported (currently OFS,
  80.       FFS,  OFS  International,  FFS International, OFS Directory Dache and
  81.       FFS Directory Cache are supported)
  82.    3. Inhibit device
  83.    
  84.    If the filesystem is supported and the ALL keyword is not set:
  85.  
  86.    4. Read root block (contains location of block allocation map = BAM)
  87.    5. Read BAM and store it (after packing, if specified)
  88.    5. Read used blocks and store them (after packing, if specified)
  89.    6. Quit
  90.  
  91.    If the filesystem is not supported or the ALL keyword is set:
  92.  
  93.    4. Read all blocks and store them (after packing, if specified)
  94.    5. Quit
  95.  
  96. Writing functions similarly.
  97.  
  98. When  writing to a filesystem, DevPack will only allow filesystems that are
  99. exactly  of  the  same  partition  size,  block size and number of reserved
  100. blocks.   If the disk should be formatted, the track size of the disk (e.g.
  101. 11 blocks for a floppy disk) must currently be equal, too.
  102.  
  103. The following parameters are supported:
  104.  
  105. FROM, TO
  106. ========
  107.  
  108. These  parameter  specifies  the source data and the destination data.  The
  109. source  is specified first and the destination second.  Either both or none
  110. of  these  two  keywords must be set.  If the one parameter is a filesystem
  111. the  other  one  must  be  a  file  and vice versa.  If both parameters are
  112. specified along with their keywords, they can be placed anywhere and in any
  113. order  of the command string.  If VIEWFILE, VIEWFILESYS or TESTFILE is set,
  114. FROM and TO must not be used.
  115.  
  116. File  names will be handled the following way:  When writing to the file, a
  117. suffix  ".pkd"  will  be  added to the file name if it's not present.  When
  118. reading  from  it and the file name doesn't contain the ".pkd" suffix, it's
  119. checked  first  if  there is a file <name>.pkd.  If this file doesn't exist
  120. then the original file name is used.
  121.  
  122. Note that copy-protected disks (i.e.  with a custom track format) cannot be
  123. handled.
  124.  
  125. Examples:
  126.  
  127. DH0: foobar           Read data from DH0: and write it to foobar.pkd
  128. foobar DH0:           Read data from foobar.pkd (foobar if not present) and
  129.                       write it to DH0:
  130.  
  131. TO foobar FROM DH0:   Read data from DH0: and write it to foobar.pkd, other
  132.                       parameters  can be placed anywhere between, before or
  133.                       after them.
  134.  
  135. PACK (or P)
  136. ===========
  137.  
  138. This  parameter  is  optional,  but  strongly  suggested.   It  may only be
  139. specified  along  with  a  READ action, because when writing to a disk, the
  140. packer type of the archive is automatically recognized.  Along with PACK an
  141. xpk  packer  name and the efficiency can be specified (separated by a ".").
  142. The  best  xpk  packers  for standard data are NUKE and SHRI.  NUKE is less
  143. efficient  than  SHRI,  but  much  faster  than  SHRI.  NUKE is 10-20% less
  144. efficient than the DMS packing algorithm, but faster.  When unpacking, NUKE
  145. is  much  faster  than  DMS  or  SHRI.  SHRI is 10-20% better than DMS, but
  146. slower.   A  general  rule is :  The less full a disk is, the slower is DMS
  147. because  DMS  always  reads  all  blocks, even if they are not put into the
  148. archive  (maybe ParCon is afraid of "lamers" who think, DMS forgets to read
  149. these blocks :-).  Note that some packer types ignore the efficience value.
  150.  
  151. Examples:
  152.  
  153. PACK NUKE    (Use NUKE packer with default efficiency)
  154. P SHRI.75    (Use SHRI packer with efficience 75)
  155.  
  156. MEMTYPE (or M)
  157. ==============
  158.  
  159. This  parameter is optional.  It specifies the memory type that is used for
  160. device  buffers.   Some  older  devices  may  require chip memory for their
  161. buffers.   For  example,  under  1.3  the  trackdisk.device  needed chipmem
  162. because  it  used  the blitter to decode the data (not because the disk DMA
  163. functions  with chipmem only).  Possible values are CHIP, FAST, ANY.  Under
  164. 2.0+ trackdisk doesn't need chipmem any longer. Default is ANY.
  165.  
  166. Examples:
  167.  
  168. M CHIP (chipmem will be used or program fails)
  169. M FAST (fastmem will be used or program fails)
  170. M ANY  (default: highest-priority memory will be used)
  171.  
  172. XPKBUFSIZE (or XB)
  173. ==================
  174.  
  175. This  parameter  is  optional  and  can only be specified along with a READ
  176. action  along with an xpk packer.  It specifies the number of device blocks
  177. to  be  buffered before packing.  If not specified, the default buffer size
  178. of  the  xpk packer is used or blocks with a total size of 65536 bytes when
  179. no  packer  is  specified.  Some packers have minimum or maximum buffer and
  180. some  packers  are  more efficient with a larger size, so this parameter is
  181. implemented.   If a packer is specified, the default buffer size is the one
  182. of  the  packer,  if  not,  it's  65536  bytes  (both will be extended to a
  183. multiple of the device block size)
  184.  
  185. Examples:
  186.  
  187. XB 200  (buffer = 200 blocks, 100KB along with a block size of 512 bytes)
  188. XB 50   (buffer = 50 blocks)
  189.  
  190. CLRUNUSED (or CU)
  191. =================
  192.  
  193. This  optional  parameter  is allowed only when writing to a disk.  If set,
  194. all  unused  blocks are overwritten with zeroes.  This has the disadvantage
  195. that  the  write operation becomes slower, but has the advantage that tools
  196. like  DiskSalv  ((C)  by  Dave  Haynie)  don't find old file fragments when
  197. trying  to  undelete  an  accidentally deleted file (deleted after usage of
  198. PackDev, of course).  This parameter is unset by default.
  199.  
  200. Example:
  201.  
  202. CU     (PackDev overwrites unused tracks with zeroes)
  203.  
  204. ETDFORMAT (or ETDF)
  205. ===================
  206.  
  207. This  parameter  is  optional.  It should be set if you want to write to an
  208. unformatted  floppy disk.  It may not function if you write to a hard disk,
  209. because  this  parameter causes PackDev to use a system format routine that
  210. functions  with floppy disks (DFx:) but may not function with other devices
  211. (like oktagon.device, my scsi device, it took hours to find this out).  The
  212. advantage  of this format routine is that label buffers can be written with
  213. it  in  one  row  (Filenotes are NOT stored here, I told this in an earlier
  214. version  of  the  doc file, ahem...).  TDFORMAT will start an extra run for
  215. the  label  buffers  (see below).  For programmers:  This causes PackDev to
  216. format with ETD_FORMAT. ETDF is unset by default.
  217.  
  218. Example
  219.  
  220. ETDF  (enhanced format routine for floppies activated)
  221.  
  222. TDFORMAT (or TDF)
  223. =================
  224.  
  225. This  parameter  is optional.  It should not be set if you want to write to
  226. an  unformatted floppy disk.  It will function if you write to a hard disk,
  227. because  this  parameter  causes  PackDev to use the general format routine
  228. that  should  function with any disk device that is supported by DOS.  This
  229. general  system  format  routine (TD_FORMAT, to be specific) is slower than
  230. the  format  routine  stated  above, because it needs an extra write run to
  231. write  the label buffers (don't ask my why, I don't know).  I don't suggest
  232. to  use  this  parameter  for  hard  disks  because  they  don't need to be
  233. Amiga-formatted.   It  is  implemented because there may exist some devices
  234. that  need formatting but don't support the enhanced routine.  TDF is unset
  235. by default.
  236.  
  237. Example
  238.  
  239. TDF  (standard format routine activated)
  240.  
  241. ALL
  242. ===
  243.  
  244. This  parameter  can  be  used when reading from a device.  If set, PackDev
  245. reads  all  blocks from the device, no matter if the filesystem is known or
  246. not.   This  is useful for all these poor demo disks that have a filesystem
  247. on  it, but also raw data on blocks that are not used by the filesystem.  I
  248. hesitated  before  implementing this parameter because I HATE disks of this
  249. kind,  but  SiliconSurfer  insisted  on  it.  Come on boys, stop these lame
  250. combination of DOS and trackloaders...
  251.  
  252. Example
  253.  
  254. ALL  (All blocks are read)
  255.  
  256. NOVERBOSE (or NV)
  257. =================
  258.  
  259. This  parameter  suppresses  the  output of the blocks currently worked on.
  260. This  is  useful  when  logging  the  output  to  a file.  It's disabled by
  261. default.
  262.  
  263. Example
  264.  
  265. NV  (no output of blocks currently worked on)
  266.  
  267. QUIET (or Q)
  268. ============
  269.  
  270. If  this  parameter  is  set, nothing is written to the standard output and
  271. nothing  is  read  from  the  standard input.  This means that Packdev will
  272. always abort if there are any problems (read/write error, ^C pressed, write
  273. on existing file etc.) and reports no error text.  It's disabled by default.
  274.  
  275. Example
  276.  
  277. Q  (No input and output)
  278.  
  279. NOCONFIRM (or NC)
  280. =================
  281.  
  282. If  this  parameter is set, PackDev will never ask for user input, i.e.  it
  283. will  immediately  start  with  the  specified  action  without waiting for
  284. confirmation.   When  errors  occur,  PackDev  will  always abort (see also
  285. QUIET).  This is useful when starting PackDev with a file as standard input
  286. or when starting it from another program. It's disabled by default.
  287.  
  288. Example
  289.  
  290. NC  (No input)
  291.  
  292. VIEWFILE
  293. ========
  294.  
  295. This  keyword will make PackDev output a file's filesystem information.  It
  296. must be specified along with a file name and nothing else.
  297.  
  298. Example
  299.  
  300. VIEWFILE foo.bar
  301.  
  302. VIEWFILESYS
  303. ===========
  304.  
  305. This  keyword will make PackDev output some information about a filesystem.
  306. It must be specified along with a filesystem name and nothing else.
  307.  
  308. Example
  309.  
  310. VIEWFILESYS DH0:
  311.  
  312. TESTFILE
  313. ========
  314.  
  315. if  PackDev  is  started  with  this parameter, along with a file name, the
  316. complete  archive is read for testing purposes.  It must be specified along
  317. with a file name and nothing else.
  318.  
  319. Example
  320.  
  321. TESTFILE foo.bar
  322.  
  323. BLOCKLIST
  324. =========
  325.  
  326. If  this  parameter  is  set along with a file name, an ASCII block list is
  327. generated,  one  line  for  each block with the block number in decimal nad
  328. hexadecimal notation.  This parameter cannot be set along with VIEWFILE and
  329. VIEWFILESYS.
  330.  
  331. Example
  332.  
  333. BLOCKLIST foobar
  334.  
  335.  
  336. PASSWORD
  337. ========
  338.  
  339. Setting  this  parameter  allows  usage of the XPK packers that are able to
  340. crypt  the data.  It can be used in combination with creating an archive if
  341. an xpk packer is used that supports crypting.  When extracting or testing a
  342. crypted  archive  you  must  specify  the password or decrypting will fail.
  343. Also  note  that  there are countries where crypting data is not allowed or
  344. restricted.   So  if  you live e.g.  in the Iran, be careful that your head
  345. isn't chopped off...
  346.  
  347. Example
  348.  
  349. PASSWORD YouWillNeverGuessThis
  350.  
  351.  
  352. Examples for usage:
  353. ===================
  354.  
  355.  
  356. Reading  the  disk in DF0:  and storing the data into RAM:disk.pkd, packing
  357. it with the SHRI algorithm:
  358.  
  359.     PackDev DF0: RAM:disk P SHRI.100
  360.  
  361.  
  362. Crypting DF0: to RAM:Secret.pkd, using the IDEA algorithm:
  363.  
  364.     PackDev DF0: RAM:disk P IDEA.100 PASSWORD StupidPassword
  365.  
  366.  
  367. Writing data from DH0:dh1data.pkd to DH1:
  368.  
  369.     PackDev DH0:dh1data DH1:
  370.  
  371.  
  372. Writing data to an unformatted floppy disk (DF1:), not asking for user input,
  373. nonstandard parameter order and creating a block list file:
  374.  
  375.     PackDev ETDF NI FROM DF1: TO DH0:disk BLOCKLIST ram:disk.blocks
  376.  
  377.  
  378. Viewing the header of a .pkd file (ram:abc.pkd; not present: ram:abc):
  379.  
  380.     PackDev VIEWFILE ram:abc
  381.  
  382.  
  383. Viewing device information of DH0:
  384.  
  385.     PackDev VIEWFILESYS DH0:
  386.  
  387.  
  388. Testing archive integrity of foobar.pkd, an encrypted archive
  389.  
  390.     PackDev TESTFILE foobar PASSWORD YohMan
  391.  
  392. v) XPK packers and their efficiency with PackDev
  393.  
  394. Here  is a list of all XPK packers I know.  Note that some seem to be buggy
  395. (HUFF  crashed with older versions of PackDev.  It was my fault, sorry) and
  396. some don't function correctly with the default buffer size (see above) etc.
  397. You  will  get a short info about them if they are installed on your system
  398. when starting PackDev.  The entries under "Packing efficiency" are produced
  399. with  a  strongly  fragmented  floppy  disk (880k size, 44% full), using an
  400. A500/030/25MHz with 4 MB Fast and 1 MB Chip RAM.  This list is not complete
  401. because  my  test  disk  is  lost  and  I  don't want to do all this again.
  402. Especially the graphical representation was hard work.
  403.  
  404. ----- Info -------   ----- Packing efficiency -----
  405. Packer     Version   Pack time    File size   Speed
  406.                      [seconds]     [bytes]  [bytes/s]
  407.  
  408. xpkMASH:     1.98     43.56s       181792      9150
  409. xpkCBR1:     1.2      25.34s       336400     15750
  410. xpkCRM2:     1.1     Library cannot be opened
  411. xpkACCA:     1.0      25.88s       228472     15450
  412. xpkCRMS:     1.1     Library cannot be opened
  413. xpkLHLB:     1.0      81.00s       188620      4900
  414. xpkSQSH:     1.10     46.74s       204340      8550
  415. xpkSMPL:     1.0      27.08s       335356     14750
  416. xpkSHRI:     2.0      87.78s       169400      4550
  417. xpkRLEN:     1.1      26.64s       329140     15000
  418. xpkRDCN:     3.3      25.80s       229836     15450
  419. xpkNUKE:     1.0      33.52s       192960     11900
  420. xpkNONE:     1.0      24.64s       413128     16200
  421. xpkIMPL:    1.0.79   174.26s       191792      2250
  422. xpkIDEA:     1.99    Cryptor, no specs determined
  423. xpkHUFF:     0.63    Functions now, no specs determined
  424. xpkHFMN:     1.28     26.16s       289696     15250
  425. xpkFEAL:     1.03    Cryptor, no specs determined
  426. xpkFAST:     1.06     38.22s       220156     10450
  427. xpkENCO:     1.0     Cryptor, no specs determined
  428. xpkDLTA:     0.1      24.84s       412932     16050
  429. xpkDHUF:     0.58     25.00s       412980     15950
  430. xpkCBR0:     1.0      25.32s       336400     15750
  431. xpkBLZW:     3.0      27.18s       242384     14700
  432. xpkRAKE:     1.5      28.60s       190484     13950
  433.  
  434.  
  435. Graphical representation of packing efficiency (incomplete)
  436.  
  437. Ratio unpacked/packed [%]
  438.  
  439.      ^
  440.      |                 + SHRI
  441.      |
  442.      |                  + LHLB           + MASH
  443.  200 +        + IMPL                                + NUKE  + RAKE
  444.      |                                 + SQSH
  445.      |                                        + FAST                ACCA,
  446.      |                                                            + RDCN
  447.      |                                                         + BLZW
  448.      +
  449.      |
  450.      |                                                            + HFMN
  451.      |                                                           + RLEN 
  452.      |                                                     SMPL +   + CBR1
  453.  100 +
  454.      |                                                              + DHUF,
  455.      |                                                                DLTA,
  456.      |                                                                CBR1,
  457.      |                                                                NONE
  458.   50 +---------+---------+---------+---------+--------+----------+-------->
  459.      0                  5000               10000               15000
  460.                                                             Speed [bytes/s]
  461.  
  462. Following  the  graph,  the  best  packer for me is RAKE when I read from a
  463. floppy drive, because gain*bytes has a maximum value for this packer.  If I
  464. wanted  to  read  from a fast device (RAD:, FFx:, DHx:), one of the packers
  465. more  to  the  left (e.g.  MASH or SHRI) may be better because the time for
  466. reading the disk will become shorter.  The more to the left the entries are
  467. here, the more they will be shifted to the right in this case and the speed
  468. will  become less important.  Unpack speed is not considered here, this may
  469. also  affect your (and my) choice.  Experiment with SHRI, MASH, NUKE, RAKE,
  470. RDCN or ACCA, they seem to be most effective.
  471.  
  472.  
  473. vi) Compatibility
  474.  
  475. This  program  needs OS V2.0+ to run.  If you want to use xpk packers (very
  476. likely),  you  need  the  xpkmaster.library and some packer sublibraries (I
  477. suggest  SHRI,  MASH,  NUKE, RAKE, RDCN or ACCA).  The xpk package and some
  478. more  sublibraries  should  be  present  in  any good pd mailbox and in the
  479. Aminet.   They  are  not  included  here  because it's much larger than the
  480. PackDev package.
  481.  
  482.  
  483. vii) Bugs
  484.  
  485. If  the  disk  should  be  formatted,  the track size of the disk (e.g.  11
  486. blocks  for a floppy disk) must currently be equal to the track size of the
  487. disk  from  which  the file is read.  This is not necessary, but coding the
  488. thing  this way is easier and faster.
  489.  
  490. Should you detect a bug, please tell me (email or phone). Be as specific as
  491. you can.
  492.  
  493.  
  494. viii) Future
  495.  
  496. What may be done in the future:
  497.  
  498. GUI  (yes, really, I will do it...tomorrow :-))
  499. Device that treats an archive like a disk
  500. Built-in packer
  501.  
  502.  
  503. What will not be done in the future:
  504.  
  505. DMS compatibility (see below)
  506.  
  507. Localization  (I  hate those zillions of useless files, there is no support
  508. for  people  who  cannot speak English.  This sounds arrogant, but I think,
  509. this tool should not be used by inexperienced users anyway)
  510.  
  511. Versions  for each type of processor (I made the experience that doing this
  512. causes  a  negligible speedup that is not worth even writing this sentence,
  513. but perhaps there will be a C compiler that can do better...)
  514.  
  515.  
  516. ix) My personal opinion
  517.  
  518. Note that PackDev will never support the DMS packing algorithm, because the
  519. current  authors  of  DMS  (ParCon)  use  stolen code from the original DMS
  520. (which  was  written  by  someone else who has not given up his copyrights)
  521. and  release  DMS  as shareware.  In my opinion, they are not allowed to do
  522. so.   It's  not  enough to assume that you can do with copyrighted material
  523. what  you want, only because you cannot contact the real authors.  It would
  524. be  OK  to  release DMS in the public domain, but making money with someone
  525. else's  code  is called FRAUD and THEFT.  It's worse than piracy - shame on
  526. you,  ParCon  !!!   Note  that  you may own pirate software if you bought a
  527. "registered"  version  of  DMS  that  has  a version greater than 1.11.  An
  528. interesting consequence:  It may not matter if you use a cracked version of
  529. DMS  or  a "registered" version.  If ParCon doesn't have the copyrights for
  530. DMS, they cannot sue for cracking it.  I've seen mailboxes that put cracked
  531. versions of DMS into their PD area for this reason.
  532.  
  533.  
  534. x) How to contact me
  535.  
  536. Christian Wasner
  537.  
  538. Phone  ++49-40-7236349
  539.  
  540. Email: u241045@niesel.dkrz.d400.de
  541.        CRISI@BLACKBOX.SHNET.ORG
  542.  
  543. If possible, use email.  If you phone me, please do it from 8pm to 10pm and
  544. don't  forget  that  I have Mean European Time here, so 8pm for you may not
  545. mean 8pm for me !
  546.  
  547.  
  548. xi) History
  549.  
  550. Aug-14 1994 V1.0 - Initial release, never released I think...
  551.  
  552. Aug-18 1994 V1.1 - Minor bugs fixed
  553.  
  554. Apr-16 1995 V1.2 - Problems  with  OFS disks fixed (PackDev didn't know the
  555.                    number of free/used blocks)
  556.                  - ALL, NOVERBOSE, QUIET and NOCONFIRM keyword added
  557.                  - Doc file corrected and improved
  558.                  - Filesystem  type  is  now  read  from block 0 instead of
  559.                    reading  it from the DOS node, because the latter always
  560.                    contains DOS\0 for Amiga floppies
  561.                  - Minor bugfixes
  562.  
  563. Apr-30 1995 V1.3 - If the partition with LIBS: on it is to be handled,
  564.                    PackDev could not open XPK (sub-)libraries, fixed
  565.                  - Minimum XPK buffer size corrected
  566.                  - TESTFILE parameter added
  567.                  - Checksums installed, in case an xpk packer doesn't keep
  568.                    them..
  569.                  - Argument handling changed (you got me, Christian...)
  570.                  - BLOCKLIST parameter added
  571.                  - PASSWORD parameter added